While 3.7 is still in beta stage, I think it is worth already starting to think
about the next generation SDL, which I guess will be the key feature of POV
4.0.

Yes, a lot has been said about this before, but I propose doing some more
systematic brainstorming.

Yes, it will be up to the POV dev team to decide on how the next generation SDL
will be like; however, they may ultimately decide to pick up a proposal drafted
by the POV community, if there is such a thing and it makes sense.


First, to keep discussion focused, I think it is prudent to distinguish between
various aspects:

- Basic paradigms: What very fundamental properties do we want? (For instance,
the question whether to use a conventional OO- or a functional approach would
fit in here, or whether the language)

- Features: What individual features do we want? (For instance, the question
whether to support Garble-Greeble-Jabberwock-trees would fit in here)

- Syntax: How do we want the features to be accessed? (For instance, the
question how to specify vectors would fit in here)

- Implementation: How can the desired features be implemented "under the hood"?

I guess syntax issues are probably not worth paying too much attention to yet,
as they may be significantly dependent on the basic paradigms or the features
to support - except when talking about basic paradigms of the syntax, so to
speak. Likewise, implementation issues may play a role in discussing the
benefits or drawbacks of other aspects, but I guess most POV users will not
give a damn how the thing works inside, provided it does so sufficiently fast.

So first thing to concentrate on is the basic paradigms and features, before
getting lost in syntax and implementation details.


So, here are a few of my thoughts:

BASIC PARADIGMS

* Multithreading Support

POV is going multithreaded. An SDL that allows to multithread parts or maybe
even all of the parsing would be of benefit there. This might be particularly
of importance for animations.

To flesh out a bit what I'm thinking about here, for instance include files
might be parsed in parallel, unless sequential parsing is explicitly requested
somehow; loops might be marked by the scene developer as fit for parallel
processing (I don't think we want to wait for an SDL implementation that can
automatically identify parallelizable loops); the SDL file may be comprised of
blocks with some hierarchy denoting parts that are independent of each other,
and can therefore be parsed in parallel.

To go a bit into implementation, too (contrary to my own recommendation, but
this one is quite independent of other conceptual issues): The parser could be
split into multiple layers; the lower layer would run in a single thread, but
just read in the scene file and include files, tokenize them, and build a
syntax tree from the tokens; the actual execution of the syntax tree could then
be delegated to a host of threads, using it to generate the geometry for the
engine to render. This would also allow a speed advantage for animations, as
the tokenization step would have to be performed just once.

* Object Orientation

I guess when talking about "the" basic paradigm on which to build the language,
we can't really get around OO these days. We obviously want an approach that is
state-of-the-art, but it also needs to be well enough understood to be both
implemented in reasonable time and efficiently usable for the average POVer, so
that leaves us with only OO or a functional approach for all I can see. And all
in all, I guess OO is much more commonly known among the POV community (and POV
developers, for that matter) than functional programming. I bet every advocate
of the functional approach will know a good deal about OO as well, but hardly
vice versa.

However, I think the most important aspect of OO for POV users would be
encapsulation of data & code, while polymorphism may play a minor role, and
inheritance may be quite well done without - provided that the language
natively supports a good set of generic data containers.

As a matter of fact, I guess a prototype-based (aka class-less) approach at
polymorphism and inheritance, like in JavaScript, would do just fine for POV
needs: While making automatic type checking impossible, I guess that's not a
major concern for the size of common POV "projects". The benefit would be a
very low "formalism profile", ultimate polymorphism, and an inheritance-like
mechanism for free.

I also think it is well acceptable for POV to maintain a conceptual distinction
between built-in types (scene entities like objects, textures, etc., but also
natively supported data containers) and user-defined objects.

As a matter of fact, a very easy way to approach this would be to mimick
user-defined entities via a built-in associative array type (aka dictionary aka
map), and just providing a specialized syntax for accessing such arrays (plus
some optimization based on the expectation that the same keys will typically be
used in many entities).

* Full-Fledged Scripting Language

On the paper, the current SDL is just a static scene description language,
extended with a preprocessor language to allow for some limited scripting
capabilities. Personally, I think this distinction is obsolete, and the new SDL
concept should acknowledge that, down to its very core.

* DOM Access

As of now, SDL can only "write" properties of the entities it describes. Some
have pondered the idea of making them readable, too, and I guess although one
can possibly go quite well without, this is a nice idea.

Similarly, users would probably expect properties to be not only writable, but
modifiable as well. Again, I'd consider this a nice idea.

* Integrated

It has been proposed to just provide an API for POV, and have each user choose
the language they prefer most. However, this would make the POV package
incomplete: You couldn't do anything with it without installing another
software (plus going through the hassle of getting your language of choice to
properly interface to the API).

Thus, even if an API would be added to allow for the use of arbitrary languages,
POV should come with its own integrated standard SDL, so you can still just
install it and get going.


FEATURES

* Namespaces

It seems like all major programming languages have acknowledged the benefit of
giving public identifiers from separate modules separate spaces to "live in",
in order to avoid name clashes.

* Container Data Structures

I think a next generation SDL will need more data containers than just arrays,
like:
- dynamic arrays
- associative arrays (aka dictionaries aka maps, kind of like arrays with
non-numeric indices)
- lists (just a bunch of entities that can be iterated over)
- ordered lists (like lists, but with a defined order for iteration; these may
also allow for access by positional index, like an array, but the mapping will
change whenever elements are inserted or removed)
- sets (lists without duplicates)

In addition, some data structure for spatial lookup may be of particular value,
like an octree or kd-tree.

* Data Tuples

Often I'd love to have a function return not only one value, but a pair of them
or even more (e.g. a point and an associated normal vector). The SDL should
provide for a mechanism to handle such cases easily.

* For Loops

Loops like #local i = 0; #while (i < n) ... #local i = i + 1; #end are
commonplace, and they work, but they suck. I want something like a #for i = 0
to n-1 ... #end.

* Foreach Loops

Iterating over all elements of a data container is commonplace, so there should
be an easy syntax for it, something like #foreach myElement in myArray ...
#end.

For data structures mapping keys to elements, the syntax should also allow for
retrieving the key along with the element, like #foreach (myKey,myElement) in
myMap ... #end; iterating over the keys only should be possible, too, like
#foreach (myKey,) in myMap ... #end, but a syntax to retrieve a list of keys
from the data container would do the same job, like #foreach myKey in
myMap.keys ... #end

* Integer values

I'm always worried when doing things with floats that I would normally use
integers for. I confess that it's probably more of a psychological thing, but
still I want integers.

* Vector and Color functions

Being unable to use vectors within functions sucks.

* Consistent functionality in functions

Being unable to use certain built-in identifiers in functions sucks, too.


SYNTAX

* Basically "C Style"

Although it's probably far too early to talk about individual aspects of syntax,
the overall "look & feel" might already make sense to discuss, or at least
gather ideas about.

I think that with so many "C Style" languages out there and enjoying a lot of
popularity (C, C++, C#, Java, JavaScript to name just the "major players" that
spring to my mind), it doesn't hurt to go for a similar style, both in overall
"look & feel" as well as various details. Not to mention that the curly braces
will maintain some feeling of familiarity :) (It seems like POV's current SDL
was inspired to some degree by C, too.) Another benefit is that POV itself is
written in C++, so the developers themselves are familiar with the style.

Personally, I'd consider only Perl- and Basic-inspired languages to be
widespread enough to use them as a basis for a new POV SDL; however, Perl is
currently undergoing significant syntax changes itself, and Basic will not gain
many supporters in the POV community I guess - let alone having no similarity
whatsoever with the current SDL syntax.

Well, there would be another option: XML. But I don't think we need to discuss
this here: XML is not particularly pretty to work with directly.

* Consistent

The current SDL is a heap of inconsistency regarding when to place a comma, when
to place a semicolon, where parentheses are used and where not (see e.g. #fopen
vs. #write), and so forth. There should be an easy, consistent style regarding
this.

* Clear distinction of types

The distinction between colors and vectors in the current SDL is to some degree
still a mystery to me; I think the two concepts should be better separated.

Similarly, I think a clear distinction between floats and vectors would be good.


Hum, well... I guess that should suffice for now...

Post a reply to this message